Date: Sun, 19 Feb 1995 09:47:00 EST From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]> Subject: Re: How to test if a server is down? In-Reply-To: NATHAN AT LSOFT.COM -- Sat, 18 Feb 1995 16:20:06 EST >On Sat, 18 Feb 1995 14:10:08 -0600 Natalie Maynor said: >>> I'd like to learn how to checkout what is and isn't down so I can >>> intelligently answer the queries I am getting. When you ask about the "server being down" I believe you are really asking about end-to-end transmission. What constitutes E-2-E xmission? Here's a first pass (in no particular order): telecom links (usually provisioned by the telephone company incl. long distance (IXC) and local operating companies (LEC) (and of course overseas circuits) routers that xmit IP packets (the atomic unit of the Internet) store-and-forward hosts such as those commonly found on bitnet e.g., UGA, PSUVM, SEARN (they need not be listserv hosts) availability of authoritative hosts for the domain name system (these guys translate host names to IP address or to other mail exchangers (MX) e.g., NETCOM.COM has 16 MX hosts that can exchange i.e., receive mail mail exchangers (MX) on the Internet correctly configured RSCS (NJE), MAILER, LISTSERV, SENDMAIL software correctly configured mail file systems with sufficient disk-space for the user sufficient bandwidth of telecom links sufficient horsepower (CPU and disk) of sending/intermediate/receiving sites Sometimes in trouble shooting, we find that the current configuration is NOW correct, but in the recent past there was a problem or change and that residual obsolete info STILL exists at intermediate sites pending a "timeout" of the cached info. There are plenty of samples of trouble shooting that have been broadcasted to LSTOWN-L and NODEINFO from such experts as Melvin Klassen (from whom I've learned alot). Tools such and various inquiries of RSCS, MAILER, SMTP, DNS (DiG or NSLOOKUP), LISTSERV (DISTRIBUTE MAIL DEBUG=YES wrt REVIEW list) are used. Sometimes they require you to be on that network: it might be impossible to inquiry of an RSCS Q from an Internet host. IMO, understanding "all" of this forms a career path. -- co-owner INFOSYS, TQM-L, CPARK-L, ERAPPA-L, JANITORS, LDBASE-L, et -L [log in to unmask] "Hot MIPS sink CHIPS" +1 814 863 1843 31 Shields Bldg. -- Penn State Univ -- University Park, PA 16802-1202 USA Date: Mon, 19 Jun 1995 16:09:00 EDT From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]> Subject: Overview: Electronic Mail Delivery Comments: To: [log in to unmask] (Permission granted to reprint, though you might want to edit for your specific installation. PMW1) Determining failure locations in electronic mail requires an understanding of numerous network functions and layers. Often times, that is the work of an e-mail postmaster. Most e-mail sites support a generic e-mail address of [log in to unmask] The job of postmaster is often done as an 'other duty as assigned' or in rare instances, not at all. As you will see, e-mail just doesn't "happen" but is the result of a complex interaction of computer processes. In general, the ability to successfully transmit electronic mail (e-mail) from a LAN-based system is due to the proper administrating and functioning of: 1) the client software -- typically a package like Eudora installed on a workstation 2) your office/department LAN as operated by your system administrator 3) a mail gateway/server such as that operated by the Center for Academic Computing 4) a data backbone such as that operated by the Office of Telecommunications, and those of external service providors 5) the Domain Name System such as operated by a number of inter-dependent host sites including the Office of Telecommunications, many times in conjunction with other departments and/or external institutions or individuals 6) the proper operation of telecommunication circuits usually operated by local exchange and long distance carriers 7) the proper administration of any name (userid) lookup schemes which is controlled by both system administrators and mail users such as operated on PSU.EDU (PH) facilities 8) the proper operation of the receiving mail server such as that operated by the Office of Administrative Systems aka oas.psu.edu 9) the proper administration of the receiver's mail box, as impacted by various security software, as well as the receiver him/herself (not allowing the mail-box to overflow) (When e-mail is sent to a LISTSERV-based list, the delivery mechanisms are even more complex. Fortunately, there are personnel at Penn State who can help trace that flow.) /Pete Weiss, [log in to unmask] -- co-owner INFOSYS, TQM-L, CPARK-L, ERAPPA-L, JANITORS, LDBASE-L, et -L [log in to unmask] "I get paid by the Byte" +1 814 863 1843 31 Shields Bldg. -- Penn State -- University Park, PA 16802-1202 USA ----- Date: Wed, 4 Jan 1995 09:27:00 EST From: "Peter M. Weiss +1 814 863 1843" <[log in to unmask]> Subject: fwd: Bouncemail top ten. Since many of these same issues have been discussed at one-time or other on LSTOWN-L, I thought that you would enjoy this compilation. Phil Agre is the author (see end for contact info). abstracted from T H E N E T W O R K O B S E R V E R VOLUME 2, NUMBER 1 JANUARY 1995 Bouncemail top ten. In running a large mailing list for the past year or so, I have become acquainted with a depressing variety of dysfunctional mail handling software. I've gathered here my top ten least favorite phenomena in hopes that a Universal Union of Large List Maintainers might spring up to force them to get fixed: 10. Mailers that give intermittent "user unknown" messages for users who perfectly well exist, perhaps because they cannot detect transient local network problems well enough to postpone delivering mail. 9. The confusion over the Errors-To: field, which sure seems like a good idea to me but which apparently is not part of the standard. It is supported by most but not all mailers. If it didn't exist then I'd have to run my mailing list from a separate account. 8. Mailers that generate messages lacking well-formed headers, most commonly addresses like "someone@local" without proper domain information. 7. Mailers that tell me "Press F1 for help with VNM error codes" even though my function keys are unlikely to be programmed the same way as they are for users at the site that generates the bouncemail message. In general, mailers designed on the assumption that all senders and recipients of messages would use that same mailer -- particularly when the mailer in question does not think in terms of standard IP domain formats. 6. Mailers that complain that a certain message could not be delivered but do not specify who in particular the message could not be delivered to. Also, mailers that complain that a forwarded message could not be delivered without providing any indication of what address(es) the message was forwarded from. 5. Vacation programs that respond to bulk or mailing-list mail or that do not keep track of who they've replied to, with the result that I get batches of spurious vacation messages (sometimes in German) as each holiday approaches. 4. Mailers that generate mail that cannot be replied to. Sometimes a message says "From: [log in to unmask]", even though the user's account is actually called "fqs". Sometimes I have no idea why I cannot reply to a message, and the mailer offers me no help in figuring it out. This is particularly annoying when the sender in question starts sending further messages to the effect of, "you should reply to my messages, you rude person!" It is even more annoying when the machine that generated the bogus message does not have a "postmaster" alias defined. 3. Mailers that take a month before giving up on the delivery of messages to a missing user, whereupon they initiate a monthlong stream of error messages, individually, for every one of the messages I've sent in the last month. 2. Mail-reading programs that automatically generate a little message to the effect of "so-and-so read your message about "routine administrative notes" on December 3rd at 08:41" -- even when the message was sent to a mailing list and not directly to the person reading it. The people whose mail readers generate these messages are usually not aware of them, and their site maintainers usually do not know how to shut them off. 1. The astoundingly baroque and uninformative error messages that I have gotten from the Novell mailer. Of course errors happen. The basic point here is that the error messages are so incomprehensible, so incomplete, so inconsistent, and so difficult to adjust or control. The right way to do this, in my view, would be for mailers to be talking to one another and maintaining updated status tables for the process of delivering (or not delivering) each message. A reasonable amount of useful information could travel over these lines of communication, and my mailer could consequently provide me with some significantly more useful functionalities. Imagine a GUI interface with a window showing the messages that got bounced, deferred, and so forth. And imagine that I could just click on each one to say, in one nice clean operation, "okay, let's just take this person off the mailing list, send them a nice explanatory note in case they're magically back on-line, and expunge from the system all remaining traces of existing messages from me to them or error messages from these mailers about them". -------------------------------------------------------------------- Phil Agre, editor [log in to unmask] Department of Communication University of California, San Diego +1 (619) 534-6328 La Jolla, California 92093-0503 FAX 534-7315 USA -------------------------------------------------------------------- The Network Observer is distributed through the Red Rock Eater News Service. To subscribe to RRE, send a message to the RRE server, [log in to unmask], whose subject line reads "subscribe firstname lastname", for example "Subject: subscribe Jane Doe". For more information about the Red Rock Eater, send a message to that same address with a subject line of "help". For back issues etc, use a subject line of "archive send index". TNO is also on WWW at http://communication.ucsd.edu/pagre/tno.html -------------------------------------------------------------------- Copyright 1995 by the editor. You may forward this issue of The Network Observer electronically to anyone for any non-commercial purpose. Comments and suggestions are always appreciated. --------------------------------------------------------------------